I don't see why these shouldn't still be template bound and then given these values as defaults in the Style setters like the other properties? Otherwise it's even harder to customize.

The issue is that we have to worry about positioning two 'areas' of the control separately: The Header and the Content. There are cases where you want the Header left aligned for example, but the actual content of the expander stretched.

What is done now is the Horizontal/VerticalContentAlignment is template bound to the content presenter. If we template bound in both areas we are forcing the header/content to always be in sync. Instead, stretching the 'container' elements allows independent positing of child content elements in either the header or the content area while also still supporting horizontal stretch.

Adding lightweight styling resources separate for the header/content area is also possible.

Agree, we should template bind the most common one that developers would want to customize and expose the other as theme resources so they can be customized as well.

Experience tells me all properties of the Expander needs to be template bound to the content area rather than the header area. It will be most intuitive that way but it's opposite of how the code currently functions so additional changes are needed. (Background/Padding, etc. map to the header) We can expose theme resources for these header properties.

Edit: I should add that WPF appears to map some properties to both the header and the content areas simultaneously. I'm not sure I agree with that approach and think we should keep them separate. This is just FYI.

I agree they should be seperate and generally we expect these properties to apply to the content area. So the control's background property should set the background of the content we provide to the control in its (metadata marked) content property.

In reply to: 590643542 [](ancestors = 590643542)

Yeah, that makes sense. But the other ones should at least be controlled by static/theme resources to provide better customization. Expander is odd because we usually see folks wanting to customize the header itself compared to the content, as the content is pretty much all end-developer driven vs. any chrome provided by the control itself at least in the default templates we've used in the past.

But the other ones should at least be controlled by static/theme resources to provide better customization

Yes, I'll add the lightweight styling resources so these can be customized without re-templating. There is well established convention for this now (but we are creating a lot of named resources indicating the styling system is deficient...)

Expander is odd because we usually see folks wanting to customize the header itself compared to the content,

I can see that point. Also keep in mind that the header is also one of the places the developer should customize the least. The design of the header is really set by the fluent design system and shouldn't change much so that end-users recognize it. It's like a ComboBox in my mind.

I added two resources to control the header's content alignment: ExpanderHeaderHorizontalContentAlignment and ExpanderHeaderVerticalContentAlignment. I am leaving the HorizontalAlignment of the header itself to stretched. This ensures it fits the grid which is the root for sizing purposes. Child content can still be aligned any way you would like (not only stretched).

This is not ideal.

• BorderThickness="{StaticResource ExpanderContentDownBorderThickness}" should be
• BorderThickness="{TemplateBinding BorderThickness}"

However, that would not work due to the BorderThickness of the control having local precedence (higher precedence than the visual state setter). The visual state is being used to switch between border thicknesses that have the top or bottom edge set to zero depending on the expand direction.

The correct solution to this is to add another filter converter for the border thickness similar to the CornerRadius. I expect push back so I didn't implement that.

What is done now is considered a hack but is usable for an initial release. Developers can still customize the thickness of the content area using ExpanderContentDownBorderThickness and ExpanderContentUpBorderThickness even while the BorderThickness of the control is ignored.

Why is this HorizontalContentAlignment no longer needed? Looking at this change it looks like the template never actually used this before. Is this just deleting unused lines?

#4394 (comment)

1. The default actually should be center per Expander Fixes #4394 (comment)
2. I followed convention of the Button template
3. When the default value of 'Center' is required, the property is simply omitted. This is better as all controls will fallback to the same default so if once in 1000 years the default was actually changed you wouldn't need to go and update all the templates (single source of truth). The rule of thumb: only change what you need to.

@tashatitova Did I misunderstand about the HorizontalContentAlignment? Were you only referring to VerticalContentAlignment in that comment referenced above?

@tashatitova Can you confirm about HorizontalContentAlignment? The more I think about it, I think this was my misunderstanding and you were only talking about VerticalContentAlignment. I would like to make this change and get this PR merged ASAP.

I just re-read it and your last comment emphasizes vertical. I'm going to make the change and add back HorizontalContentAlignment. Horizontal seems like it should be Left so @StephenLPeters was right to point this out.

Have you tested that this works? I'm worried that if you override the ExpanderHeaderBorderBrush at the local scope the ExpanderContentBorderBrush wont see your override. This is because the resource lookup doesn't restart when a resource redirection is encountered. So when the template is expanded and this resource is found, we'll start looking for a value for the ExpanderHeaderBorderBrush from our current position in the tree walk, which will miss the local overrides lower in the tree.

Have you tested that this works

No, I have not tested this specifically and didn't have a reason to at the time. My changes here were only renaming and I copied the original functionality. Code before renaming is below:

ExpanderBorderBrush renamed to ExpanderHeaderBorderBrush
ExpanderDropDownBorderBrush renamed to ExpanderContentBorderBrush

Resource resolution is tricky to understand for those outside the codebase and is not well documented at least that I've found. So I'll take your word for how it functions in this area. If you want me to make the change that's fine. It will just be set to CardStrokeColorDefaultBrush as well.

Edit:

I'm worried that if you override the ExpanderHeaderBorderBrush at the local scope the ExpanderContentBorderBrush wont see your override

Actually, that's probably not a bad thing. If you change the Header resource one wouldn't expect the Content to change with it. Either way this line of code should be modified as indicated above.

Note ExpanderHeaderDisabledBorderBrush is also affected but would make sense to follow the ExpanderHeaderBorderBrush when changed. Still, this should change as well due to potential resource lookup issues.